home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7016 < prev    next >
Encoding:
Text File  |  1996-08-05  |  5.7 KB  |  127 lines

  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.os.msdos.programmer,comp.lang.c
  4. Subject: Re: open vs fopen?
  5. Date: 17 Feb 1996 00:59:59 -0600
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4g3udf$6pe@solutions.solon.com>
  8. References: <uEYFxc9nX8WX083yn@mbnet.mb.ca> <4ftusv$181@newshost.cyberramp.net> <danpop.824430285@rscernix> <4g39d4$ej8@newshost.cyberramp.net>
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. In article <4g39d4$ej8@newshost.cyberramp.net>,
  12. John Noland <sinan@cyberramp.net> wrote:
  13. >In article <danpop.824430285@rscernix>, danpop@mail.cern.ch says...
  14. >>In <4ftusv$181@newshost.cyberramp.net> sinan@cyberramp.net (John Noland) writes:
  15. >>>The open() function and its ilk are normally referred to as the "low-level"
  16. >>>I/O package. fopen() is the "Buffered" or "Standard" I/O package. The 
  17. >>>strength of the low-level I/O functions is that they offer excellent control,
  18. >>>particularly when used with binary files.
  19.  
  20. >>???  What can read/write do on a binary file that fread/fwrite cannot do?
  21.  
  22. >Where in the above did I compare them with each other? 
  23.  
  24. Well, "they offer excellent control, particularly when used with binary
  25. files" would imply that they can do things that the others can't.
  26.  
  27. >>>If you have a special I/O need, you
  28. >>>can use the low-level I/O routines to fashion the exact I/O package to fit
  29. >>>your needs. 
  30.  
  31. >>Same question as above.
  32.  
  33. >Same question from me again. Are the read/write functions written using fread/
  34. >fwrite or is it vice versa? I believe, and feel free to correct me if I'm 
  35. >wrong, that the fread/fwrite functions are written using the read/write 
  36. >functions.
  37.  
  38. They are sometimes.  Sometimes it's done the other way, and sometimes it's
  39. all done in terms of the native syscalls which may be different.  But, you
  40. failed to answer his question:  In what way can you customize the
  41. low level calls that you can't the high level calls?  There are answers,
  42. but they have *nothing* to do with C.
  43.  
  44. >>>The standard I/O package is one such creation. It is designed to provide fast
  45. >>>buffered I/O, mostly for text situations.
  46. >>               ^^^^^^^^^^^^^^^^^^^^^^^^^^
  47. >>???
  48.  
  49. >I use the stdio routines almost exclusively myself. Even for binary files. 
  50. >That doesn't make the above statement wrong. Your statements seem to imply 
  51. >that all systems are buffered at the OS level, so who cares what I/O 
  52. >approach you use. You're not going to see any difference in I/O speed no 
  53. >matter what. While this may be true for your particular situation, it's by 
  54. >no means universal. The usefulness of buffering is in working sequentially
  55. >with a file. This makes buffered I/O well suited for text files. That 
  56. >doesn't mean you can't or won't read a binary file sequentially or that it 
  57. >sucks for use with binary files. Which, judging from what you've written,
  58. >is exactly what you'll think I meant. 
  59.  
  60. Well, binary files benefit just as dramatically from buffering.  Simple
  61. test programs run on the order of 10 times faster for me using stdio instead
  62. of the low level calls, unless they consciously make an effort to act like
  63. the stdio buffering - in which case, why bother?  stdio does it better than
  64. I do.
  65.  
  66. >>>When fopen() is used, several things happen. The file, of course, is opened.
  67. >>>Second, an external character array is created to act as a buffer. The 
  68. >>><stdio.h> file has this buffer set to a size of 512 bytes.
  69.  
  70. >>To a default size of _minimum_ 256 bytes.  I'm typing this text on a
  71. >>system which uses a default buffer size of 8192 bytes.  The size of the
  72. >>buffer can be controlled by the programmer via the setvbuf function.
  73.  
  74. >That's a big default buffer. How many disk accesses does it take to fill 
  75. >that thing? I seriously doubt you would want a buffer that big when reading 
  76. >a file randomly. But, maybe your system is so fast you can afford that kind 
  77. >of waste. In my <stdio.h> file, the constant BUFSIZ is 512. You say that 
  78. >you can control the size of the buffer using setvbuf(). That's true, but it
  79. >doesn't change the default buffer size as you seem to imply. If I do the 
  80. >following:
  81.  
  82. >FILE *input, *output;
  83.  
  84. >input = fopen("myfile.in", "r+b");
  85. >setvbuf(input, NULL, _IOFBF, 1024);
  86.  
  87. >output = fopen("myfile.out", "w+b");
  88.  
  89. >do you think output points to a buffer of the size set by setvbuf?  I don't 
  90. >think this is what you meant. 
  91.  
  92. No, what he probably means is that, on his system, BUFSIZ is 8192.  This
  93. is not atypical.  It probably takes one disk access; it's a common disk
  94. block size on BSD-like unix systems, and probably on many others.  In
  95. which case, it takes about the same time to read a 1k block as to read
  96. an 8k block.
  97.  
  98. But your system's BUFSIZ has *nothing* to do with the language spec; as Dan
  99. says, 256 or larger is ok.
  100.  
  101. >>The same applies to other operating systems (e.g. Unix) except that they
  102. >>do a much better job at buffering I/O than MSDOS.
  103.  
  104. >Some versions of UNIX don't do any buffering at all.
  105.  
  106. Well, they can be told specifically not to, but I haven't *ever* seen or
  107. used one that doesn't buffer pretty dramatically.  I'm accustomed to
  108. working with projects with a megabyte of source, and doing entire edit/build/
  109. test cycles without disk activity.  That's about a 6 meg buffer.
  110.  
  111. >>So many inaccurate statements don't clarify things.  On the contrary.
  112.  
  113. >The shit you have to up with when trying to be helpful. 
  114.  
  115. Makes sense; if you say a lot of things which are only partially true, or
  116. untrue, you aren't being very helpful, and people are likely to complain.
  117.  
  118. Not to mention, the whole low level IO thing is really not very much a
  119. part of C.
  120.  
  121. -s
  122. -- 
  123. Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach.
  124. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  125. FUCK the communications decency act.  Goddamned government.  [literally.]
  126. The *other* C FAQ - ftp taniemarie.solon.com /pub/c/afq - Not A Flying Toy
  127.